Enterprise systems are frequently tested to determine how changes to a system will affect its performance. The testing can be accomplished with simulations, where an application related to the system is executed, and data is input to determine how the system will perform. Previous simulation mechanisms worked relatively well for monolithic enterprise system architectures. However, enterprise systems increasingly employ a service-oriented architecture (SOA) where data access is enabled via services. An SOA in an enterprise context may frequently be referred to as an enterprise services architecture (ESA).
Traditional ESA restricts services to be stateless. In contrast to the monolithic system that monitored each separate action or access to a system, traditional ESA may require that each transaction be self-contained. The state of the transaction may not be persisted in the system. Thus, simulation within an ESA system is very commit-based. Simulations must either be limited to a single logical unit of work (e.g., a single activity, a single request), or requests must be executed and changes made to the backend, which then must be undone if it is decided that the changes made in the simulation are not to be kept. Such a setup is very inconvenient seeing that many simulations are intended to last a relatively short period of time (on the order of minutes). A lot of time and effort is traditionally spent to deal with the limitations in simulating within an enterprise employing SOA. There is currently no logical mechanism to link simulation activities in an SOA architecture. Additionally, even if linking of the simulation activities were possible, previous simulation techniques had predefined sequences of events or simulation activities to follow. The predefined sequences resulted in a significant lack of flexibility in simulation.